Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, process modeling may be used to provide integration of business applications both within and across enterprise organizations.
Thus, such modeling languages allow a flow of activities or tasks to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
In the context of such processes, as just referenced, it may be that one or more of the constructs in the process model may be computationally complex or otherwise difficult to evaluate. For example, one or more types of synchronization points in the process model may be computationally complex or otherwise difficult to evaluate because of the number of branches and predecessor branches converging at a point. Also, different types of synchronization points may be configured to be enabled based on different parameters. For instance, one type of synchronization point such as an inclusive merge gateway (hereinafter called the OR-join) may depend on the presence or absence of events in places in the process model that are far away from the synchronization point.
Further, in real-world scenarios, it may occur that the enablement of the synchronization point may be unnecessarily delayed because of the computationally complex nature of evaluating whether or not the process may proceed beyond the synchronization point, thus delaying the execution of subsequent tasks. For example, a business process model may include multiple tasks, executing in parallel, that are each related to processing and checking shipment feasibility for purchase orders, and that converge at a synchronization point. The synchronization point may or may not need to wait on all of the incoming tasks to complete before proceeding to subsequent tasks. It may be that subsequent tasks may be completed without all of the preceding tasks in the process being completed, because some tasks may be unreachable. However, the subsequent tasks may be unnecessarily delayed if the synchronization point is not enabled because it is waiting on a task to complete, where the task is no longer active or may be unreachable. For example, as different shipping options are evaluated, one type of shipping option task may not be attainable, yet the entire process may be delayed if the fact that a particular shipping option is not attainable cannot be evaluated in a timely manner. Consequently, for example, subsequent tasks, such as allocating an order to shipment, may be significantly delayed.
Frequently, it may be difficult or problematic to express and evaluate such synchronization points in a manner that is executable as a process model. Thus, in these and other cases, process models may fail or be limited in their goal of expressing real-world processes in a flexible, repeatable, computer-executable manner.